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DETAILED ACTION 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/14/10 
has been entered. 

Response to Amendments/Remarks 

2. Applicant's arguments filed on 5/14/2010 with respect the rejection(s) of claim(s) 
1-25 under 35 U.S.C. 103(a) are fully considered, but not persuasive. 

3. Applicant's arguments on the independent claims 1 , 8-9, 1 8-20 (as admitted by 
Applicant that they have "similar features", last paragraph of page 1 1 ) are moot because 
all them are amended to which new ground rejections are made. 

4. For claim 1 1 , Applicant argues: 

"There is no description of a loop-avoidance router field in an ant packet or anything equivalent to a loop- 
avoidance router field described in the cited art. The Office Action relies on lines 1-3, Step 4 of Di Caro on 
page 327 to allegedly teach the feature. This is the same passage that is quoted above in the arguments 
for Claim 1 . The Office Action comments that this passage describes "cycle avoidance." This is incorrect. 
The passage describes cycle detection. The passage in DiCaro, "If the cycle lasted longer than the 
lifetime of the ant before entering the cycle..." suggests that an ant is allowed to enter a cycle, and thus a 
cycle is not avoided" (last paragraph, page 12); 

In response, Examiner respectfully disagrees: 
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Caro discloses that the forward ant only visits the neighboring nodes that it has 
not visited before ("choosing among the neighbors it did not already visit", line 2, page 
327). By doing so any loop is avoided since the forward ant must visit a node at least 
twice in order to form a loop. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1-8, 18-20 are rejected under 35 U.S.C. 103(a) as being unpatentable 
overTeruhi et al (US 20030072269, hereinafter Teruhi, which includes IETF standard 
for RTP, RFC 1889, as cited by Teruhi in [0045]) in view of Apostolopoulos, et al., INTF 
RFC 2676 "QoS Routing Mechanisms and OSPF Extensions", August 1999 (hereinafter 
RFC 2676) 

For claims 1, 8, 18-20, Teruhi discloses a method, a non-transitory computer- 
readable medium and an apparatus for updating a routing table ("routing table", [0053]; 
or suggested by OSPF, [0003], which updates a routing table), comprising the 
computer-implemented steps of: 

sending a first data packet only to a particular router that the first data packet has 
not already visited (first RTCP-SR sent from node 1 1 to node 12 in FIG. 9; note that first 
packet has not visited the router); 
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wherein the particular router is associated with a first actual path is a shortest 
path among all paths associated with routers in the set of routers (selecting a router 
from a set of routers associated with link 31-33 which has a shortest path to a 
destination, as shown in FIG. 18, that has the shortest path from the source node 1 1 to 
the destination node 12); 

wherein the first actual path has been updated with a previous actual path taken 
for a previous data packet to travel to a previous destination indicated by the previous 
data packet (routing table is updated based on previous traffic, [0007]); 

receiving a second data packet (first RTCP-RR sent from node 12 to node 1 1 in 
FIG. 9) that indicates an second amount of time taken for a destination back to the 
sending router (the time between the first RTCP-RR packet is sent from Node 12 and 
the time it arrives at Node 1 1 , FIG. 9, as disclosed by Section 6.3.2 in page 28 of RFC 
1889); 

wherein the destination indicated by the first data packet is the same as the 
previous destination indicated by the previous data packet (FIG. 10, RTCP-RR packet is 
sent to the destination following a path in the routing table built based on the previous 
data packet); 

wherein the second data packet is sent from the destination indicated by the first 
data packet (FIG. 9, where RTCP-RR is sent from the destination of RTCP-SR); 

wherein the method is performed bv one or more computing devices (the router 
shown in FIG. 18). 

Teruhi is silent on the following: 

the shortest path is measured in terms of a shortest time (a first actual time); 
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updating the shortest time based on the second time (the trip time of the second 
packet from the destination to the sending router); and 

updating the routing table based on information contained in the second data 
packet. 

In the same field of endeavor (routing), RFC2676 teaches finding the shortest 
path (OSPF, page 1) in terms of traveling time (delay, line 8 of first paragraph in Section 
1 .2, Page 5, which is the time difference between the time that a RTCP packet leaving a 
node A and the time the packet arrives a node B, and is equivalent to the actual 
traveling time from the node A to the node B) from the routing table that are updated 
based on the received packets ("the QoS routing table that gets built as the algorithm 
progresses ... at each (hop count) iteration, intermediate results are recorded in a QoS 
routing table", 2 nd paragraph, page 12), which is the shortest time of the all the previous 
packets traveled from the set of nodes to the destination node. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Teruhi with RFC2676 to choose the shortest path 
(in term of traveling time) and update the first (shortest) time and the routing table 
based on the information from the second packet for the benefit of efficiency of network 
because they are analogous. 

As to claim 2, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
further comprising: updating a path associated with both the destination and the 
particular router (by considering the particular router as the sending router in claim 1). 
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As to claims 3 and 6, Teruhi in view of RFC 2676 discloses the method of Claim 
1; Teruhi is silent on the second data packet information including the bandwidth 
available on a path taken by the second data packet. 

RFC 2676 teaches the routing packet containing QoS information ("QoS routing", 
1 st paragraph of Page 5), including bandwidth information ("available bandwidth", Line 7 
of Section 1 .2, Page 5). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to include bandwidth information in the second packet for the 
benefit of efficiency of providing better routing options. 

As to claim 4, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
whether a path taken by the first data packet is feasible (a path found based on updated 
routing table is feasible). 

As to claim 5, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
further comprising: updating, based on information contained in the second data packet, 
a list of routers that indicates all routers in a path taken by the first data packet to a 
router that sent the first data packet to a present router (This is equivalent to finding the 
shortest path based on the updated routing table with the information of the second data 
packet). 

As to claim 7, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
based on information in the second data packet , updating the second data packet to 
indicate that a path taken by the first data packet is not feasible (as discloses in parent 
claim 1 in that the information in the second packet in combination with the information 
in the first packet provides a metric of round trip time and routing table uses the metric 
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to find the shortest path; if the path is not the shortest one, the path taken by the first 
data packet is not the feasible path). 

7. Claim 1 -9 and 1 1 -25 are rejected under 35 U.S.C. 1 03(a) as being 1 03(a) as 
being unpatentable over Gianni Di Caro et al., "AntNet: Distributed Stigmergetic Control 
for Communications Networks", Journal of Artificial Intelligence Research, 12/98 
(hereinafter Caro) in view of RFC 2676 (which includes the recited RFC 1247). 

For claim 1, 8 and 18-20 Caro discloses a method of updating a routing table 
("the routing table", page 327, step 3), comprising the computer-implemented steps of: 

sending a first data packet (sending forward ant, step 1 of page 326, line 1-3) 
only to a particular router that the first data packet has not already visited ("choosing 
among the neighbors it did not already visit", line 2, page 327); wherein the first time 
has been updated with a previous time taken for a previous data packets (the routing 
table is built based on previous routing data packets); 

receiving a second data packet that indicates an second amount of time from 
taken for the destination back to the sending router (receiving backward ant, step 5 of 
page 327); 

selecting the path according to a criterion that the first packet is predicted to 
reach the destination, wherein the second data packet is sent from the destination 
indicated by the first data packet ("The backward ant takes the same path as that of its 
corresponding forward ant, but in the opposite direction", step 6, page 328); 

updating the shortest time based on the second time ("updates .. the traffic M_k", 
step 7, page 328 in view of "The model M maintains absolute distance/time estimates", 
3 rd paragraph, page 326); and 
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updating the routing table based on information contained in the second data 
packet ("updates ... the routing table", step 7, page 328-329); 

wherein the method is performed by one or more computing devices (the routers 
on the path upon which forward and backward ants travel). 

Caro is silent on the criterion for the shortest path is based on the shortest time 
(the first time, which is a shortest time that the first packet is predicted to reach the 
destination); 

In the same field of endeavor (routing), RFC2676 teaches routing the shortest 
path in term of traveling time (delay, line 8 of first paragraph in Section 1 .2, Page 5). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Caro with RFC 2676 to choose the shortest path (in 
term of traveling time) and update the first (shortest) time and the routing table based on 
the information from the second packet for the benefit of efficiency of network because 
they are analogous. 

As to claim 2, Caro in view of RFC 2676 discloses the method of Claim 1 , Caro 
further discloses the method comprising: updating a path associated with both the 
destination and the particular router ("updates ... the routing table", step 7, page 328). 

As to claims 3 and 6, Caro in view of RFC 2676 discloses the method of Claim 
1 , but are silent on the second data packet information including the bandwidth 
available on a path taken by the second data packet. 

RFC 2676 teaches the routing packet containing QoS information ("to support 
QoS", Line 3 of Section 1.2, Page 5), particularly bandwidth information ("available 
bandwidth", Line 7 of Section 1 .2, Page 5). 
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One skilled in the art would have been motivated to apply the teaching by RFC 
2676 to the second packet to provide additional information for better routing options. 
Furthermore, OSPF technology taught by 2676 is cited by the applicant in the 
disclosure. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to include bandwidth information in the second packet for the 
benefit of efficiency of providing better routing options. 

As to claims 4 and 7, Caro and RFC 2676 disclose the method of Claim 1 , 
whether a path taken by the first data packet is feasible (a path predicted to take a 
shortest time from the source node to the destination node is always feasible). 

As to claim 5, Caro and RFC 2676 disclose the method of Claim 1 , Caro further 
discloses the method comprising: updating, based on information contained in the 
second data packet, a list of routers that indicates all routers in a path taken by the first 
data packet to a router that sent the first data packet to a present router ("updates ... 
the routing table", step 7, page 328-329). 

For claim 9, Caro discloses a method of updating a routing table (Node routing 
table, page 331, line 6), the method comprising the computer-implemented steps of: 

for each neighbor router in a set of neighbor routers predicted to be required for a 
data packet to travel to a specified destination ("every network node", line 1 of step 1 , 
page 326), associating the neighbor router with an amount of time ("elapsed_time", 
page 331 , line 1 9; or step 2 of page 326); 
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receiving a forward ant data that indicates the specified destination (suggested 
by "The backward ant takes the same path as that of its corresponding forward ant, but 
in the opposite direction", step 6, page 328; or algorithm shown in page 331); 

selecting, based on one or more first specified criteria (goodness of ant's travel 
time, title and first paragraph of Section 4.2, page 330; or step 3 of page 327), a subset 
of the set of neighbor routers (from page 331 , line 14-20 where forward ant can only be 
passed to neighboring routers one at a time; selecting from the routing table a subset of 
neighbor routers through which paths to the destination go); 

in response to receiving the forward ant data packet, selecting, from the subset 
of neighbor routers, to the specified destination, among amounts of time associated with 
neighbor routers in the subset of neighbor routers (the paths from the routing table are 
updated based on received forward ant data packet, first paragraph of Section 4.2, page 
330; or "updates the corresponding statistics and the routing table", step 7); 

wherein the one or more first specified criteria comprise a criterion that no 
neighbor router in the subset of neighbor routers is in a list of routers already visited by 
the forward ant data packet ("choosing among the neighbors it did not already visit", line 
2, page 327); 

wherein the amount of time has been updated with a previous amount of actual 
time taken for a previous data packet to travel to the specified destination ("step 7 i) of 
page 328, where Mk that includes travel time information is updated based on previous 
travel time of ants; or algorithm shown in page 331 ); 
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sending the forward ant data packet to the particular neighbor router ("destination 
node is reached", step 5, page 327; or LaunchForwardAnt (destination_node, 
source_node), lines 10-12, page 331); 

receiving a backward ant data packet that indicates a second amount of time 
taken for the forward ant data packet to travel to the specified destination ("The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328; the travel time is the second amount of time); 

wherein the backward ant data packet is sent from the specified destination ("The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328); 

determining, based on information indicated in the backward ant data packet, 
whether one or more second specified criteria are satisfied (line 5-30 of page 331 , 
determining a path based on criteria specified in M=Local traffic model and T=Node 
routing table); and 

if the one or more second specified criteria are satisfied (a second time criteria 
used to find proper path based on M and T; notice that criteria used for selecting paths 
depend on user requirements and may have multiple values), then performing steps 
comprising: 

updating the first amount of time based on the second amount of time 
(suggested by UpdateLocalTrafficModel, line 24 of Page 331 ; where traffic model is 
updated); and 

if one or more third specified criteria are satisfied (suggested by "The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
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opposite direction", step 6, page 328, which indicates the backward ant knows whether 
the path taken by the forward ant is followed, which is equivalent to the path feasibility 
flag), then updating, based on information indicated in the backward ant data packet, 
the routing table (suggested by UpdateLocalRoutingTable, line 26 of Page 331). 

Caro does not explicitly disclose selecting a particular neighbor router that is 
associated with a first amount of time that is a lowest amount of time, but defines a 
goodness in terms of trip time ("as estimated using the associated trip time", line 27-34 
of page 329) that is used as a measure for determining routing between nodes. 

In the same field of endeavor, RFC 2676 discloses OSPF extensions on routing 
based on path QoS parameters (lines 1-5 of page 3). Since time delay is one of most 
important QoS parameters, it would have been obvious to one skilled in the art to use 
the shortest trip time (delay time) as the criteria for the shortest path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Caro with RFC 2676 to selecting a particular 
neighbor router that has a lowest amount of delay time from source node to the 
destination node in searching the best routing. 

As to claim 11, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the method comprising: 

determining whether any neighbor router in the set of neighbor routers is 
associated with an amount of time that is lower than the first amount of time ("as 
estimated using the associated trip time", line 27-34 of page 329); and 

if any neighbor router in the set of neighbor routers is associated with an amount 
of time that is lower than the first amount of time, then updating the forward ant data 
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packet to indicate a present router in a loop-avoidance router field of the forward ant 
data packet ("choosing among the neighbors it did not already visit", line 2, page 327; 
the loop is avoided since the forward ant does not visit any neighboring node that it has 
visited before). 

As to claim 12, Caro in view of RFC 2676 discloses the method of Claim 1 1 , 
Caro further discloses wherein a loop-avoidance router field ("memory of their paths and 
of the traffic conditions found", lines 1 -2 of step 2 in page 326) of the backward ant data 
packet indicates a router indicated by the loop-avoidance router field of the forward ant 
data packet (notice that a backward ant packet has the same structure as forward ant 
packet). 

As to claim 13, Caro in view of RFC 2676 discloses the method of Claim 12, 
Caro further discloses wherein the one or more second specified criteria comprise a 
criterion ("trip time", line 10 of page 329) that the router indicated by the loop-avoidance 
router field of the backward ant data packet is not contained in a list of routers that the 
forward ant visited after visiting a present router (step 3 of page 327, line 1-2; notice that 
a backward ant packet has the same structure as forward ant packet). 

As to claim 14, Caro in view of RFC 2676 discloses the method of Claim 9, but is 
silent on wherein the one or more specified criteria comprise a criterion that the second 
amount of time is lower than any other amount of time, relative to the specified 
destination, among amounts of time associated with neighbor routers in the set of 
neighbor routers. 
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However, the criterion that the second amount of time is lower than any other 
amount of time is used in OSPF (disclosed by RFC 2676) in determining the shortest 
path in term of time. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to specify criterion that the second amount of time is lower than 
any other amount of time in order to find the shortest path. 

As to claim 15, Caro in view of RFC 2676 discloses the method of Claim 9, but 
are silent on the method comprising: determining whether a router from which the 
backward ant data packet was received matches a router associated with the 
destination in the routing table; and if the router from which the backward ant data 
packet was received does not match the router associated with the destination in the 
routing table, then updating a path feasibility flag of the backward ant to indicate that a 
path taken by the forward ant is not feasible. 

However, the method requires the forward ant packet and the backward ant 
packet go through the same route (in opposite direction). If the backward ant packet 
cannot following the same route as the forward ant packet, the ant packet will be 
destroyed according to Caro ("if an ant is forced to return to an already visited node, the 
cycle's nodes are popped from the ant's stack and all the memory about them is 
destroyed", step 4 of page 327). It is a common practice in the art that one way of 
destroying/delete a packet is to set a flag of the packet so that it can be destroyed at 
proper time or location (such as taught by Tarin, US 2001/0000536 A1 , "deleted cells 
are marked by a flag", [247]). 
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Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to set a flag of the received backward ant packet if routing 
information of the packet does not match the routing table of the router in order to 
comply with the protocol. 

As to claim 16, Caro in view of RFC 2676 discloses the method of Claim 1 5, 
Caro further discloses the one or more third specified criteria comprise a criterion that 
the path feasibility flag of the backward ant indicates that the path taken by the forward 
ant is feasible (suggested by "The backward ant takes the same path as that of its 
corresponding forward ant, but in the opposite direction", step 6, page 328, which 
indicates the backward ant knows whether the path taken by the forward ant is followed, 
which is equivalent to the path feasibility flag). 

As to claim 17, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the one or more third specified criteria comprise a criterion that a path 
taken by the forward ant data packet from a present router to the specified destination 
does not include any routers that are identified in a potential upstream node list 
(suggested by "The backward ant takes the same path as that of its corresponding 
forward ant, but in the opposite direction", step 6, page 328, which indicates the 
backward ant knows whether the path taken by the forward ant is followed, which is 
equivalent to the path feasibility flag). 

As to claim 21, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, 
based on information contained in the second data packet, a path associated with both 
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the destination and the particular router ("updates ... the routing table", step 7, page 
328-329 or UpdateLocalRoutingTable, line 26 of Page 331 ; the routing table includes all 
the paths, including a path associated with both the destination and the particular 
router). 

As to claim 22, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet ("updates ... the 
routing table", step 7, page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), 
an indication of an amount of bandwidth available ("characterized by a bandwidth", lines 
10-1 1 of page 322) on the path taken by the second data packet (the path is disclosed 
by "The backward ant takes the same path as that of its corresponding forward ant, but 
in the opposite direction", step 6, page 328). 

As to claim 23, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet ("updates ... the 
routing table", step 7, page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), 
whether a path taken by the first data packet is feasible (suggested by "The backward 
ant takes the same path as that of its corresponding forward ant, but in the opposite 
direction", step 6, page 328; a mechanism that ensures the path is feasible based on 
the updated routing table). 
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As to claim 24, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet, a list of routers 
that indicates every router in a path taken by the first data packet from a router that sent 
the first data packet to a present router (suggested by "The backward ant takes the 
same path as that of its corresponding forward ant, but in the opposite direction", step 6, 
page 328). 

As to claim 25, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet to indicate an 
amount of bandwidth available (routing table is "characterized by a bandwidth", lines 10- 
1 1 of page 322) on the path taken by the second data packet (bandwidth available is 
considered as a criterion of feasible path in algorithm specified in steps 1-7 of pages 
326-330, which includes routing based on bandwidth). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jianye Wu whose telephone number is (571)270-1665. 
The examiner can normally be reached on Monday to Thursday, 8am to 7pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Seema Rao can be reached on (571)272-3174. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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